Desktop applications have grown significantly in both size and functionality, mostly in response to the demands of users for more features. For example, the Word word-processing program manufactured by the Microsoft Corporation of Redmond, Wash., is reputed to include about four million lines of software code. Software vendors have found that application development costs, schedules and quality control issues escalate in a non-linear fashion (e.g., exponentially) as the size of the application increases.
Much of the same functionality is provided in different applications. For example, word processors, presentation software and spreadsheets all usually include font packages, i.e., software code that controls the presentation of text by these applications. These applications also all can include spell checkers, table layout software, illustration software, etc. This means that there is redundant code in different software applications.
Vendors have simplified software structures, increased reuse and improved quality by developing interoperable compound document models. A traditional (non-compound) document is a monolithic structure that is stored in a single uniform file, and is processed by a single application. The traditional document can include different elements, such as pictures, words, tables, graphs, etc., but every part of the document is composed, changed and saved (e.g., to a hard disk) using a single application that is typically purchased from a single vendor.
For example, a given document includes two pieces of text, a graphic, and a spreadsheet. The entire document is handled by a single application, such a word processor (such as Word) that incorporates the functionality necessary to handle all of the different elements. Typically, a user will cut and paste elements from other applications via a temporary memory area provided by the operating system, such as the clipboard. For example, a spreadsheet created in a spreadsheet application such as Quattro Pro, manufactured by the Borland Corporation, is cut from the spreadsheet application and pasted into a document being handled by the word processing application. In another example, a drawing can be created using an application such as the Illustrator application manufactured by the Adobe Corporation and clipped out and pasted into a Word document. The drawing can also be stored as a separate file and then inserted into the Word document using the Word application. However, it is typically not possible to modify the inserted or pasted element without leaving the word processor. In some cases, it is indeed possible to use the word processing application to edit elements created by other applications and inserted into a document handled by the word processor. But this functionality has been added to the word processor at considerable expense. Such added functionality is responsible for the runaway increase in size, complexity and inefficient redundancy in desktop applications, such as word processors.
Compound document frameworks are the desktop software industry""s attempt to correct this situation. In the compound document paradigm, a document is no longer monolithic, but rather a heterogeneous assemblage of different xe2x80x9cparts.xe2x80x9d Thus, the example document discussed above includes four different xe2x80x9cpartsxe2x80x9d (the two text parts, the spreadsheet part, and the graphic part) or three xe2x80x9cpart typesxe2x80x9d (text, spreadsheet and graphic). All of these xe2x80x9cpartsxe2x80x9d are contained with a xe2x80x9ccontainer part.xe2x80x9d The container part helps describe the relationships of the parts that it includes. This represents a redesign of the architecture of, for example, document manipulation software. Parts that are not container parts are called xe2x80x9ccontent parts.xe2x80x9d Examples of content parts include a text part, a graphic part, a spreadsheet part, etc.
Unlike traditional documents, compound documents are not manipulated by a single document editor. Rather, each part type of the document is handled by a separate, independent xe2x80x9cpart editor.xe2x80x9d For the example document discussed above, there are three part type editors: one for text, one for spreadsheets and one for graphics. A part editor is software adapted to modify a part of a compound document, and can include an animation editor, a video editor, an audio editor, and a software development editor. These part editors work cooperatively. As the user moves her cursor from one part of the document to another, the appropriate part editor becomes active. Different menu bars and buttons can appear that give the user options for manipulating the part over which the cursor lies. Each part editor is an independently created piece of software. Each editor handles its own interaction with the user, printing a part, and sending representations of that part to and from persistent storage (e.g., a hard disk) and/or to and from networks.
Part editors offer an important advantage to the user because the graphic editor can be used inside a document, a presentation, a source code editor, etc. in the same way, i.e., with the same or substantially the same interface. This is superior to traditional systems where the user must learn to use a different interface to do the same thing (e.g., manipulate a graphic) in every different application she uses. There can also be many different part editors of the same type, e.g., many different graphic editors. The user can advantageously choose her favorite, and then use it for all documents that conform to the compound document model.
The compound document model also creates opportunities for small independent companies to create and sell software for manipulating documents, because the high cost of entry into the desktop software market is lowered because of the smaller size of part editors compared to traditional, multi-functional applications. This can increase competition, spur innovation and create new options for the user.
A part editor is typically created in the context of a particular software framework, such as OpenDoc, created by the Apple Computer company of Cupertino, Calif. (see  less than http://www._opendoc._com, visited Dec. 19, 1999 greater than , Object Linking and Embedding (OLE), created by the Microsoft Corporation, etc.
Compound document frameworks have been intended for use on desktops. Certain known systems have individual parts that can automatically update themselves from remote network locations. For example, the CyberDog OpenDoc container application (see  less than http://www.cvberdog.org/, visited Dec. 19, 1999 greater than can include a HyperText Transfer Protocol (HTTP) client that updates itself via client pull or server push technology. However, known compound distributed document frameworks such as CyberDog are disadvantageously not network-enabled in a uniform, intuitive and general manner.
A shared computing environment such as a Multi-User Domain (MUD) and MOO is an electronic community to which many users can connect. Such a shared environment typically provides text-based facilities for virtual conversations, creating extensions to the shared environment, creating and programming software objects in the shared environment, etc. Examples of such environments include LambdaMOO (see  less than http://_vesta._physics._ucla._edu/xcx9csmolin/lambda/, and lambda.moo.mud.org 8888, visited Dec. 19, 1999 greater than , TinyMOO (a MUD Object-Oriented that is designed for social interaction), etc. MUD users connect to MUD servers using ASCII (text, ASCII Character Set Revised, ANSI X3.1 10-1983, ftp://dkuu.dk/i 18n/WG15-collection/charmaps/ANSI X3.110-1983 visited Dec. 19, 1999 greater than ) client such as emacs, or even a terminal. Commands can be used to produce utterances (e.g., xe2x80x9cHello, Bobxe2x80x9d), emote (e.g., xe2x80x9cBob wavesxe2x80x9d), traverse the MUD or MOO world (e.g., go north), etc. There are different regions (known as rooms) in the environment. A room can contain objects that respond to typed-in commands. Interactions (i.e., conversations and emotes) are typically confined to the room in which the user is located at the time the utterance is made by the user.
MUDs and MOOs have powerful programming facilities that allow users to create richly interactive domains, interconnect them in interesting ways, and fill them with inviting objects. However, MUDs and MOOs have several important shortcomings. They are disadvantageously limited to using ASCII characters, i.e., they provide no Graphical User Interface (xe2x80x9cGUIxe2x80x9d). MUDs and MOOs also disadvantageously are only very superficially integrated with the desktop. Thus, although ASCII strings can be cut and pasted from desktop applications, it is not possible to drag and drop images, graphics, tables, etc. from desktop applications into the MUD or MOO client. The MUD/MOO software is disadvantageously isolated from the desktop. It is not possible to interoperate desktop software elements (e.g., OLE, OpenDoc, etc.) with a MUD/MOO client. For example, to add fonts and images to a MOO, it is necessary to re-implement and introduce those functions into the MOO software.
In accordance with an embodiment of the present invention, a MUD client is implemented as a container document in a compound document framework. A distributed version of the compound document framework is created while advantageously retaining the social and/or cognitive aspects of the MUD/MOO experience, and the user experience, software architecture, and software reuse features of the compound document environment.
One embodiment of the present invention includes a system for modifying a compound document in a client/server architecture. A client having a client processor executes client compound document multi-user domain software. A client memory is coupled to the client processor. The client memory stores a copy of a shared container part of a compound document, a shared content part of the compound document, and a client part editor.
The client is coupled to a MUD server, e.g., through a network. The server has a server processor that executes server compound document multi-user domain software. The server also has a server memory that is coupled to the server processor. The server memory stores a copy of the shared container part of the compound document, a shared part of the compound document, and a server part editor. The server receives a part modification signal from said client, modifies the shared part of the compound document, and sends a signal to the client updating the client""s copy of the modified shared part of the compound document. The signal is sent to the client, and can be sent to other clients, in accordance with a concurrency model.